Managed service provider system for collaborative healthcare scheduling, credentialing, and compliance across shared suppliers

ABSTRACT

An MSP platform provides contingent healthcare worker recruiting and shift assignation in a multilayered process of job order broadcasting, competency matching, proposals from healthcare agencies aka vendors, screening, compliance management, and onboard of each candidate. Each staff profile submitted has to go through multilayered review, approval, and orientation process. Additionally, each healthcare worker&#39;s calendar, credential, and compliance have to be managed across multiple employers to prevent scheduling conflict and compliance violations, and guaranteeing full visibility of all healthcare workers across the entire supply chain. MSPs (Managed Service Providers) have the ability to service a large number of facilities on whose behalf the MSPs generate job orders for contingent workforce, and manage fulfillment using suppliers (aka vendors) mapped to the facility being serviced. The supplier ecosystem is a cohesive block that may be shared across all MSPs, and several such MSP ecosystems should be allowed to coexist in the system. Suppliers can be tiered by geography allowing a large vendor network to track demand from one or more healthcare facilities across a single location or a group of vendor locations. Additionally, a facility that is part of an MSP should also be able to work directly with all suppliers either in conjunction with or independent of an MSP. Both long term assignments referred to as ‘Travel’ position, and on-demand shift assignments referred to as ‘Day-to-day’ position are serviceable under this centrally available software commonly referred to as ‘Software as a Service’.

FIELD OF THE INVENTION

The invention relates to methods and a managed service provider (MSP)system for managing collaborative credentialing, compliance, andscheduling of contingent healthcare workers by multiple MSPs andhealthcare facilities. More particularly, the invention relates toautomatically fulfilling job requisitions, either travel or day-to-dayworkers, by employing services of suppliers available across the MSPsystem.

DISCUSSION OF THE RELATED ART

The traditional credentialing, compliance, and scheduling systemsoperate independently, and without an integrated process spanning thehealthcare facility's stakeholders, the suppliers' stakeholders, and thehealthcare workers. Such systems may be addressing the needs of a singlehealthcare facility in isolation without taking into account the overalldemand, thereby creating an architecture that is built on simpledata-exchange mechanism failing to see the overarching demand andavailability in the context of the ecosystem. When workers are onboardone or more healthcare facilities, then the system for identifying theirreal-time availability is also not integrated. Lacking this level ofcohesion and visibility, the current systems disenfranchise workers aswell as process participants, which leads to inconsistent and incompletecredentialing and compliance, with added disadvantage of taking longerfill-cycles not in line with the hiring timeline and objectives of ahealthcare facility.

Existing systems lack ability to create and manage shared supplier poolthat can be dynamically configured within minutes to serve any group ofhealthcare facilities or MSPs. Systems also lack automated features toenable outsourcing of contingent staffing to an MSP, especially forhealthcare systems that own several hospitals; additionally, suchsystems lack the ability to create facility-specific configurations thatvary from facility to facility. Accommodating each facility's uniquecircumstances and needs are therefore cumbersome, people intensive, andalso lack a common communications platform with automated follow-ups,accountability, and life-cycle tracking of both the job order or thehealthcare worker.

Existing systems also are not capable of automating process flows forengaging and alerting all stakeholders when posting, proposing, andonboard of a worker. This is because the worker, or candidate, profilehas to flow through several layered steps that require collaborationbetween several stakeholders across both healthcare facility andsuppliers. Typically the existing processes do not have a process fabricto seamlessly transition a worker profile across various stakeholdersresponsible for different organizations functions; these steps are jobpostings, responses, screening, interview scheduling, offer acceptanceand contract compliance, credentialing, health record audits, HRacceptance, Health Services acceptance, facility and departmentalorientation scheduling, and orientation delivery. With so manystakeholders, there is also a need to communicate all errors, omissions,and exceptions during this multitier process, and maintain its history.

With absence of a cohesive process across stakeholders and contributors,the ability to collect historical evidence for corroboratingeffectiveness of each individual step is absent. This is a seriousdrawback for harvesting lifecycle events for gaining operationalintelligence that could be useful in optimization of core operations.Systems also lack real-time monitoring and alerting about non-complianceor non-employability, which are essential for patient safety andadhering to state regulations.

Existing systems also lack real-time scheduling features across multipleemployers. The ecosystem of suppliers is not provided the tools tomanage, monitor, and allocate workers across multiple employers. A majordrawback of such systems is inability to take automated actions withoutmanual intervention—for example, a shift that is announced automaticallyvia VoIP (Voice-over-IP) or SMS (text messaging) would not be feasiblein the absence of real-time calendaring; to assume that it is possibleto do this without real-time information is to break all etiquette ofcommunication and basically spam the suppliers and their workers with adeluge of irrelevant notifications about an opportunity that the workeris unable to fill.

SUMMARY OF THE INVENTION

Thus, a majority of healthcare facilities require contingent staff toensure correct patient to healthcare worker ratio to avoid risksassociated with being short staffed or overworked workers. Depending onthe type of service a healthcare worker provides, however, regulatoryorganizations mandate who can provide direct service to patients. Theseregulatory requirements warrant credentialing, background, and healthcompliance verifications to ensure patient and healthcare worker safety,and avoid lawsuits when there is patient injury or death. It is oftenrequired to reproduce the compliance stance at a given point in historyas proof of proper governance in hiring contingent workforce. Insummary, a healthcare worker cannot provide services until the worker isproperly whetted, oriented, and continuously tracked for any complianceviolation.

For example, an expiring license, certification, or immunization wouldbe considered out of compliance, and the healthcare worker has toreplace the expiring document or prevented from providing patient care.Therefore, each such healthcare worker, after receiving clearance, hasto be put into a qualified worker pool for a specific facility—onlythose workers who are in this pool can provide services at the saidfacility.

Real-time availability information is also important for creatingmultidimensional searchable view based on 5 key dimensions for informedon-demand shift provisioning—this dynamic view is constructed usingdepartment, job class, shift type, shift date, and worker availabilityand compliance. When this level of information is not easily available,it is impossible to create rich collaboration experience.

An MSP system for contingent staffing has 8 major components: (1)Ability to setup multiple MSP organizations, each servicing a number ofhealthcare facilities, which manage unique business relationshipsbetween healthcare facility and suppliers, (2) An ecosystem of suppliersand their healthcare workers shared across all MSPs. (3) A collaborationplatform for all MSPs to coordinate with, and on-behalf-of, eachhealthcare facility serviced by MSP—ability to publish jobs acrosssuppliers and receive automated candidate proposals, (4) An integratedworkflow for various approvers/coordinators in the onboard of acandidate to include following steps—screening, interview scheduling,offer acceptance and contract compliance, credentialing, health recordaudits, HR acceptance, Health Services acceptance, facility anddepartmental orientation scheduling, and orientation delivery, (5) Atracking mechanism for all contingent staff for managing theiremployment lifecycle, history, and real-time compliance information, (6)Real-time virtual calendar of contract staff across multiple employersfor day-to-day on-demand shift scheduling, (7) Multi-dimensionalscheduling view to instantly schedule the most eligible candidate, and(8) Automated timecard generation, with mobile clock-in/clock-out.

The disclosed embodiments include a method for creating an MSP'sSupplier (aka. Agency) ecosystem. The supplier ecosystem is shared withother MSPs. This effectively creates a marketplace between MSPs andsuppliers. Each supplier can create its individual locations, and groupsuch locations into national and regional hierarchies. Such groupsbelong to the same EIN (Employer Identification Number), which enablestracking of business operations at local, national, or regional level.

The suppliers are mapped to customers. Such customers are healthcarefacilities created and uniquely configured. In some embodiments, themethod creates departments specific to a healthcare facility. The methodalso creates job-classes mapped to specific departments. No other jobclasses can be used for onboarding healthcare workers if the job classhas not been mapped to the department. The method also creates shifttypes unique to a facility and its departments, which represent start ofshift, end of shift, total hours, and total permissible mealtime/breaks.All timecards and scheduling functions use shift types.

The method also creates unique credentialing steps later used forcreating a dynamic checklist-menu during the compliance audit and HRacceptance processes. The method also creates unique health compliancesteps later used for creating a dynamic checklist-menu during thecompliance audit and health services acceptance processes. The methodalso creates performance evaluation criteria specific to a healthcarefacility. The method also creates profile elements specific to ahealthcare facility. The profile elements are mapped to specific jobclasses for dynamic profile-menu creation ensuring that unrelatedprofile elements remain hidden in the menu. The method also identifiesdynamically those elements that require an accompanying document to beverified and approved during onboard.

Each agency has its administrators that create healthcare workers'profiles and a virtual calendar in the staff pool. An agencyAdministrator electronically submits all credential and healthcompliance documents. Profile elements that can be submitted includeLicenses, Certificates, Identification, Education, Employment History,References, Skills/Specialty Assessment Worksheet, Confidentiality andHIPAA Form, Yearly Competency Assessment, Background Verification(EPLS/SAM, Medi-Cal License Suspension and Ineligible Provider Check,NSOPW, OIG, any additional background checks desired), Physical ExamResults, Medical Questionnaire, Immunizations Records (Mumps, Rubella,Rubeola, Varicella, TDAP, Hep B, Influenza), 10 Panel Drug Test, Drugand Alcohol Policy, FIT Test, TB Screening (PPD Skin Test, QuantiFERONTest, Chest X-Ray), TB Questionnaire, and additional profile data asrequired by each healthcare facility. Because a healthcare worker may beemployed by several agencies, each agency maintains a separate profilefor healthcare worker as the profile is a portfolio of documents thatthe agency guarantees to be accurate, authentic, and validated by thesubmitting agency. Each profile entry has meta-data describing eachdocument's validity and expiry period.

The Agency Administrator also manages the virtual calendar for eachday-to-day worker. The virtual calendar is accessible by all agenciesand healthcare facilities where the healthcare worker is employed. Thecalendar viewed by an agency, however, displays only those shifts thatare contracted through the agency. The calendar viewed by a healthcarefacility displays only those shifts that are pertaining to the facility.All other calendar entries are obfuscated.

The method creates compliance managers with responsibility for verifyingall compliance related documents for specific set of healthcarefacilities and its suppliers. The intersection of authorized healthcarefacilities and authorized suppliers is the scope of access for thecompliance manager.

The method also creates job orders, or requisitions, for electronicbroadcast to suppliers. Broadcast of job orders can be limited toselected suppliers, can be sent to all suppliers in a single broadcast,or may be sent in batches on a deferred basis. Deferring allowsresponses from preferred vendors first.

The method is used by agency administrators to respond to a job order byproposing one or more candidates best suited for the job order. Joborder is surfaced in the supplier's requisition queue, from where theAgency Administrator can select a specific job order and propose aviable candidate for the job by using an automated search for matchingall qualified healthcare workers. The search shows all constraints inthe context of the job order, compliance violations, and history of pastand current proposals for each candidate along with their currentonboard status with various healthcare facilities. This prevents oversubscription of healthcare worker and avoids unnecessary withdrawals foran over-extended worker.

On proposing a candidate, the Agency Administrator can monitor the joborder in the requisition queue as the candidate moves through variousstages of the onboard process at the facility where proposed, thereforeexperiencing complete transparency in the entire onboard process.Additionally, the Agency Administrator receives alerts during onboardfor additional documents, errors and omissions, interview date, offeracceptance, orientation dates, and alerts for cancelled or deniedorders.

Responses for a job order are received by the MSP Staffing Manager. Theresponses may be from one or more suppliers, and each supplier maypropose one or more healthcare workers. The MSP or facility-sideresponse queue is called the Onboard Queue. Each entry in Onboard Queuerepresents one response, and each response follows a collaborativeworkflow, as disclosed below.

A method for an MSP Staffing Manager starts the first step of thecollaborative onboard process by screening the candidate for fitmentafter which the candidate profile is forwarded to the interview step.While forwarding, the MSP Staffing Manager can provide the name of theinterviewer, typically a department manager. If there are morecandidates for a job order, then the additional candidates are held asbackup. The Agency Administrator is informed when the candidate isselected for onboard, and all other candidates are moved in the backupqueue for the agency from where such profiles may either be left asbackup or recalled by the Agency Administrator for proposing to otherhealthcare facilities.

The candidate profile after successful screening is moved to theDepartment Manager, Interviewer, and Queue. Upon review of the screeningdocument, the interviewer electronically sends an interview date to boththe healthcare worker and the agency employing the healthcare worker.Upon completing the interview, a candidate is either approved or denied.An approval forwards the candidate to the next stage of onboard.

The candidate profile after successful interview is moved to thecompliance manager queue. The compliance manager has two distinctqueues. One for receiving all credentials required by HR and the otherfor receiving all health documents required by Health Services. Adynamic view is generated for the compliance manager, wherein alldocuments marked relevant for credentialing in the context of thehealthcare facility are laid out in a tiled fashion in the top-half ofthe view with the ability to download and verify each documentseparately or as one consolidated document. For the bottom half, anotherdynamic view is generated, wherein both the credentialing checklist-menuand the health checklist-menu is laid out in a tiled fashion in thebottom-half of the compliance manager view with ability to check-markeach step as verified. If the profile could not be verified due toomission, negligence, illegible documents, or expired documents, then anautomated notification with relevant comments are sent to the AgencyAdministrator for remedial action, and the profile is marked in theCompliance Manager Queue as ‘Agency Alerted’. In response to this alert,the Agency Administrator certifies taking remedial action to address alldeficiencies, which in turn marks the profile in the compliance managerqueue as ‘Agency Responded’ and shows the response received.

The candidate profile after checklist approval is moved to the HRAdministrator and Health Services Administrator queues. Both HR andHealth Services personnel verify and approve each candidate in a mannersimilar to the compliance manager using identical user interface andsoftware logic, except that both HR and Health Services personnel mayalso revert a profile back to the compliance manager for furtherinvestigation.

The candidate profile after checklist approval is moved to theorientation scheduling step in the collaborative workflow. Theorientation schedule is copied from a modifiable template, updated forthe current requisition, and sent to both the healthcare worker and itsAgency Administrator. The orientation schedule consists of dates, time,and reporting instructions. Soon after orientation is completed, thecandidate is verified for successfully completing all the assignedorientation steps.

The candidate profile after Orientation checklist approval is moved tothe final step in the collaborative workflow where the contract's startand end date may be altered and alerted to both the agency and thecandidate. The conclusion of this final step stages the candidate in thefacility's staff pool for tracking the contract history, real-timecompliance, performance evaluation, and several other attributes of ahealthcare worker with respect to his/her employment with the facility.On conclusion of the contract period as specified in the job order, ifthis candidate is resubmitted for a new job order in the future, thenthe entire onboard process for this healthcare worker may be eitherrepeated, bypassed, or certain steps may be selectively bypasseddepending on the length of time that the worker has not worked at thesame facility or in the same department.

A method is used by the MSP Staffing Manager for searching, inviting,and confirming shifts from available compliant-healthcare workers usinga 5 dimensional drilldown approach to include Departments, Job Class,Shift Types, Date, and time intersection, and displaying the 5dimensional data for multi-department, multi-class, multi-shift type,multi-date, and multi-worker selection. This view is derived fromexisting shift allocations attached to job orders for the healthcarefacility and virtual calendars of healthcare workers across the entiresupplier ecosystem, wherein each shift has a backing timecard accessibleby healthcare worker using mobile device.

An additional method is used by the MSP Staffing Manager for searching,inviting, and confirming shifts from available compliant-healthcareworkers by constructing date specific vertical swim-lanes grouped bydepartment. This view is derived from the virtual calendars ofhealthcare workers across the entire supplier ecosystem. Each shift hasa backing timecard accessible by healthcare worker using mobile device.

An additional method is used by the MSP Staffing Manager for searching,inviting, and confirming shifts from available compliant-healthcareworkers by constructing date specific horizontal swim-lanes by availablestaff. This view is used for distributing a multiday order betweencandidates by mix-and-match, with automated VoIP based interaction toconfirm multiday availability. This view is derived from the virtualcalendars of healthcare workers across the entire supplier ecosystem.Each shift has a backing timecard accessible by healthcare worker usingmobile device.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are included to provide further understandingof the invention and constitute a part of the specification. Thedrawings listed below illustrate embodiments of the invention and,together with the description, serve to explain the principles of theinvention, as disclosed by the claims and their equivalents.

FIG. 1 illustrates an MSP ecosystem according to the disclosedembodiments.

FIG. 2 illustrates a supplier ecosystem according to the disclosedembodiments.

FIG. 3 illustrates the MSP structure and key processes according to thedisclosed embodiments.

FIG. 4 illustrates sample elements of a healthcare facility customconfiguration according to the disclosed embodiments.

FIG. 5 illustrates a sample profile for verification of credentialingand compliance documents according to the disclosed embodiments.

FIG. 6 illustrates a flow diagram for a collaborative process accordingto the disclosed embodiments.

FIG. 7 illustrates an example job-order queue for an MSP according tothe disclosed embodiments.

FIG. 8 illustrates an example job-order queue for a supplier accordingto the disclosed embodiments.

FIG. 9 illustrates an example search and match screen that shows alleligible candidates to a supplier according to the disclosedembodiments.

FIG. 10 illustrates an example screen of a supplier submitting one ormore candidates according to the disclosed embodiments.

FIG. 11 illustrates a MSP view of the screening queue according to thedisclosed embodiments.

FIG. 12 illustrates the MSP's Position Control forwarding a candidate toan interview queue according to the disclosed embodiments.

FIG. 13 illustrates a screen of the MSP of the interview queue accordingto the disclosed embodiments.

FIG. 14 illustrates the screen of the queue for an interviewer accordingto the disclosed embodiments.

FIG. 15 illustrates the interviewer date selection screen according tothe disclosed embodiments.

FIG. 16 illustrates the interview date display according to thedisclosed embodiments.

FIG. 17 illustrates the screen for the MSP view of the offer queueaccording to the disclosed embodiments.

FIG. 18 illustrates a screen showing offer negotiation and confirmationaccording to the disclosed embodiments.

FIG. 19 illustrates the screen of the MSP view of a compliance managerqueue according to the disclosed embodiments.

FIG. 20 illustrates a screen showing the compliance manager queueaccording to the disclosed embodiments.

FIG. 21 illustrates a screen for individual health document review andapproval according to the disclosed embodiments.

FIG. 22 illustrates a screen for individual HR document review andapproval according to the disclosed embodiments.

FIG. 23 illustrates a screen of the MSP view of an orientation queueaccording to the disclosed embodiments.

FIG. 24 illustrates a screen showing the MSP Staffing Manager creatingan orientation schedule according to the disclosed embodiments.

FIG. 25 illustrates the screen showing verification of orientation stepsaccording to the disclosed embodiments.

FIG. 26 illustrates the screen for the MSP view of completion oforientation according to the disclosed embodiments.

FIG. 27 illustrates a screen showing final step to mark onboardcompleted according to the disclosed embodiments.

FIG. 28 illustrates a selection criteria screen for creation of a5-dimensional view according to the disclosed embodiments.

FIG. 29 illustrates a screen of the 5-dimensional view on executingsearches according to the disclosed embodiments.

FIG. 30 illustrates a screen of selection criteria for creation of a3-dimensional view according to the disclosed embodiments.

FIG. 31 illustrates a screen for the 3-dimensional view on executingsearches according to the disclosed embodiments.

FIG. 32 illustrates a screen for a consolidated view for a supplier fromall healthcare facilities according to the disclosed embodiments.

FIG. 33 illustrates a search screen for VoIP multiday schedulingaccording to the disclosed embodiments.

FIG. 34 illustrates a MSP pre-VoIP view screen for VoIP-enabledinvitations for day-to-day job orders according to the disclosedembodiments.

FIG. 35 illustrates the MSP view screen showing the healthcare worker inthe invited queue according to the disclosed embodiments.

FIG. 36 illustrates the supplier view screen when the healthcare workeris moved to the BID queue on accepting the shift(s) according to thedisclosed embodiments.

FIG. 37 illustrates the supplier view screen when the healthcare workeris moved to the confirmed queue on accepting the shift(s) according tothe disclosed embodiments.

FIG. 38 illustrates an MSP system.

FIG. 39 illustrates a computing device configured to execute thefunctionality disclosed in the MSP system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Aspects of the invention are disclosed in the accompanying description.Alternate embodiments of the present invention and their equivalents aredevised without parting from the spirit or scope of the presentinvention. It should be noted that like elements disclosed below areindicated by like reference numbers in the drawings.

The process of ensuring healthcare worker compliance and credentialingis fraught with inefficiencies, errors, omissions, visibility, and poortracking. This is because of the fact that there are many participantsin the process of identifying, screening, and assigning shifts tohealthcare worker. The complexity of interactions is explained below.

FIG. 1 shows the MSP ecosystem 100 according to the disclosedembodiments. First tier of complexity arises in creating a collaborativeecosystem wherein a large number of healthcare facilities 102 use a setof suppliers 104. Different healthcare facilities 102 use the samesubset of a larger ecosystem. The relationships between such anexpansive ecosystem has to be mapped to ensure that a new facility canbe up and running with a supplier ecosystem in a few hours rather thanmonths of RFPs, contract negotiations, etc. By the same token, asupplier should be able to plug itself into this ecosystem and startsupplying in matter of hours to a preexisting customer base. Anotherdimension of complexity is when an MSP 106 provides total outsourcingsolution for staffing operations that includes contract management,compliance management, day-to-day staffing, invoicing, and otherstaffing and support services.

FIG. 2 shows a supplier ecosystem 104 according to the disclosedembodiments. Whether a supplier 202 is a single-location shop or amulti-location national supplier, the suppliers essentially arecompeting for available healthcare workers 204 in the market, andessentially are hiring workers that can be working at other suppliers.In this shared ecosystem 104, there is constant battle to get a joborder to ensure that the supplier can provide contingent healthcareworker with continued income or risk losing the worker to a competitor.The opportunistic aspect of the worker pool creates another level ofcomplexity. Each employer has to maintain its own worker profile andensure its accuracy and validity. By the same token, the MSP platform100 prevents collisions of submissions of the same healthcare workerthrough multiple suppliers at the same facility. Through a fairnesssystem, the healthcare worker acceptance by a healthcare facility from aspecific supplier essentially prevents other suppliers from submittingthe same candidate.

Complexity of Electronic Record Keeping, Credentialing, and Compliance

The credentialing and compliance repertoire is very extensive. A subsetof this profile is shown in FIG. 3, and the requirements could vary fromfacility to facility. Where applicable, the element within the profilewill have a corresponding expiry date, which has to be trackedcontinuously and various stakeholder alerted ahead of time before suchdocuments expire. When a supplier 202 is working with large number ofhealthcare facilities 102, or when the healthcare facility is workingwith a large number of suppliers then it becomes difficult to track thisinformation flow, including the verification required for both correctlysubmitted documents, or new versions of document requested in case ofexpiring documents. Additionally, a repository of current documents andhistorical documents has to be maintained for audit purpose, and shouldbe available on demand. Given the high volume of contingent workersgoing through larger healthcare facilities every year, the complexity ofsubmitting, reviewing, approving, replacing, and reporting on suchdocuments without a management system means error prone and inefficientprocess fraught with risks. The MSP system 100 has taken this processfrom several weeks and compressed it to just few hours as evidenced byreal world benchmarking.

Complexity in Chain-Of-Approval and Accountability

FIG. 6 in the section MSP Platform for Contingent Staffing below showsthe entire process from job-order creation to completion of all onboardsteps that finally qualifies a worker for shift assignments. Thenumerous suppliers that may bid for a job-order, propose one or morecandidates, and the various stakeholders that would screen, interview,audit, approve/deny, and orient a candidate requires an integratedprocess to include all participating entities, including the worker. Insuch a process, the documents and information has to move from onestakeholder to another in an orderly fashion while maintaining theintegrity and sanctity of the documents, notes captured by each processcontributor, and keeping historical evidence of the entire process forforensics and reporting. One key aspect of the forensics is optimizationof process and analyzing where the process bottlenecks exist, and whichgroup of contributors is responsible for slowing the process, and mayrequire more resources or training.

Complexity in Deriving Business Metrics for Business and ProcessOptimization

Contingent staffing spend is attributed to various cost centers inhealthcare facilities. C-suite requires visual representation to assessthe impact of contingent staffing on organizations performance measurefrom various metrics, chiefly cost, time-to-onboard, job-orderturnaround, supplier performance, risk, patient-to-staff ratio, shortageof specific skill set, patient satisfaction, etc. These metrics derivedby mining the data provide insight into various parameters that could beadjusted to improve quality, cost, and risks.

Complexity of Scheduling On-Demand Day-To-Day Staff

The most difficult situation arises when Day-to-Day shifts are requiredto be filled. Without a virtual calendar capturing all assignments of astaff across multiple employers, vacations, non-availability, and othertypes of schedule blocks, there is no visibility into the worker'savailability. The only option in this case is to broadcast the shiftsacross a wide network, which disincentivizes the suppliers, as theeffort required in contacting, confirming, reciprocating back with anavailable resource could be met with a rejection when there are severalrespondents. The market is therefore disdainful about participating insuch random markets, which causes serious availability issues forhealthcare facilities, as too few suppliers want to play in this market.

FIG. 3 shows the MSP structure and key processes according to thedisclosed embodiments. MSP platform 100 may be used for contingentstaffing. The MSP solution discussed here addresses all of theabove-mentioned complexities by creating a electronic marketplace foronboard of both healthcare facilities (the customers) and staffingagencies (the suppliers), with ability to form self-contained networksbetween healthcare facilities and suppliers. An MSP platform 100 withresponsibility of outsourced contingent staffing operations could createits own customer ecosystem within this platform to service and manage. Ahealthcare facility 102 which does not need the services of a MSP, cancreates itself as an MSP and manage its group of hospitals and itssuppliers. A supplier 202 can create a multi-location presence bycreating all of their independent locations and then aggregating themusing the unique EIN# for its organization. All of these differenthierarchies provide ability for each entity to manage their businessoperations at the MSP level, facility level, or supplier level. Eachentity can also self-onboard their ecosystem, thereby using the MSPplatform 100 as a true platform for enabling commerce betweenparticipating entities as further elaborated with the help of the FIG. 3below.

FIG. 3 illustrates key principles in MSP platform 100 architecture. Theconcepts disclosed therein are elaborated upon in FIGS. 1, 2, 4, 5, and6. FIGS. 5 and 6 are disclosed in greater detail below.

MSP platform 100 includes the following key elements. First is theability to create and configure MSPs 106 that receive the privilege ofestablishing their presence in the platform and use the services of theplatform to serve healthcare facilities 102 by managing their contingentstaffing operations. A healthcare facility 102 can be its own MSP, or agroup of facility (example: a hospital system) can also create its ownMSP or use services of an outside MSP entity.

Another ability is one by the MSP 106 to create and configure customers.Each customer is uniquely configurable so as have services vary inbehavior dynamically at run-time without requiring programmatic changes.These customizable configurations 400 are shown in FIG. 4, which depictssample elements of a healthcare facility 102 custom setup.

The MSP 106 creates and configures suppliers 202 as either independentlocation, or creates a multi-location supplier. Each such supplier isidentified as either providing TRAVEL healthcare workers (meaning 1-14weeks of contract) or providing DAY-TO-DAY healthcare workers (meaningOn-Demand as the need arises, contract period is open ended), orproviding both types of contingent workforce. Suppliers 202 can addthemselves and expand their locations within the MSP platform 100through self-registration. All suppliers 202 are visible to all MSPs 106and to all healthcare facilities 102 even when a specific MSP has addeda particular supplier to the ecosystem.

Each supplier location has the ability to add workers to its pool thatwill be then proposed to various job orders originating from thehealthcare facilities. For each worker 204, the supplier 202 has tosupply credentialing and compliance information as shown in FIG. 5,which depicts a healthcare worker profile 500.

MSPs 106 have the ability to do mapping between the hospitals and thesupplier locations that service them. This restricts the number ofsuppliers based on the preferred vendor list approved by the healthcarefacility.

At its core the MSP platform 100 has a powerful Collaborative OnboardPlatform that allows MSP 106 or its constituent facilities to requestfor healthcare workers 204 with either TRAVEL or DAY-TO-DAY contracts.This Onboard Platform brokers all requests for healthcare workers usingJob-Orders, and then engages all stakeholders who have to review andapprove the candidates. Additionally the platform 100 prevents collisionbetween suppliers that propose the same candidate to a facility. Theplatform 100 also prevents suppliers from overcommitting the worker byalerting the supplier on overlapping contracts and shifts.

All healthcare workers 204 that have been qualified and successfullyadded to a facility's pool are then available to be scheduled for longterm or short-term assignments based on their designation as eitherTRAVEL or DAY-TO-DAY workers. The DAY-TO-DAY scheduling platform is atthe core of MSP platform 100 for providing automated scheduling usingmultidimensional day-to-day scheduling wherein hundreds of shifts forthe entire healthcare facility 102 can be scheduled in minutes byconsulting the virtual calendar for each qualified worker that completedonboard for day-to-day contracts.

MSP platform 100 encapsulates and hides the complexity involved inpublishing and fulfilling a job order for a healthcare worker 204 to alarge supplier network of ecosystems 104. MSP platform 100 also receivesand processes the candidates through a complex onboard process. Asdisclosed in FIG. 6, there may be 8 steps involved in the end-to-endprocess, each involving a pipeline of 8 queues through which ahealthcare worker 204 profile should pass through before successfullymeeting all the criteria for qualification and ready to deliver patientcare. Each queue identified below may be managed by different entities.Responsibilities for each queue depend on how a MSP 106 or a healthcarefacility 102 has distributed them.

As shown in collaborative onboard process flow bar 600, the process maybe broken into 7 segments. These segments may be screening, interview,offer, MSP check, facility check, orientation and completion. Aftergoing through these segments, then a healthcare worker is ready forassignment to shifts within MSP platform 100.

Once a job-order is created to onboard a new healthcare worker in step602, it is staged both in the MSP's Job-Order Queue and Supplier'sJob-Order Queue from where the supplier 202 will propose eligiblecandidates along with a screening document. These actions occur in thesearch, match, and propose process embodied in step 604.

The submitted candidates will be staged in the Screening Queue 606wherethe MSP or facility position controller will review the screeningdocument and approve or deny a proposed candidate. If more than onecandidate is offered for a job-order, then when a candidate is selected,other candidate profiles are marked as backup profiles and put intoholding pattern for reconsideration should the original candidate chosenfor onboard is no longer available or fails to meet the onboardrequirements. On successful screening, the candidate is moved to thenext stage of the process, which is the interview segment of process600. A list of interviewers or department managers are listed for theirauthorized departments, and the candidate is moved into the InterviewerQueue 608. Position-Controller can post additional information whileforwarding the candidate profile to the Interview Queue.

The interviewer will electronically send a specific interview date.Email, VoIP, and text are available channels. The interviewer completesthe interview, posts the results of the interview, and forwards thecandidate profile to the MSP/ Facility Offer Queue 610.

Offer Queue 610 includes a two-step process. First the offer is signedand sent by the facility officer with signing authority. The supplieracknowledges the offer by counter signing it. The offer step provides achat session for facilitating negotiations and additional terms. Oncompletion of the Offer segment of process 600, the candidate profile isforwarded for credentialing and compliance verification to theCompliance Manager's Audit Queue 612.

In the audit segment of process 600, the compliance manager will verifyall submitted documents for accuracy, errors, omissions, and validity,before approving the candidate profile to be sent to the facility HR andHealth teams for final review and approval. The audit segment is made upof two steps. One step is for documents relevant to the facility's HRteam, and the other for the facility's Health Services team. On approvalof all documents in the audit steps, the profile is moved to two queues,HR and Health Queues 614.

In the HR and Health Queues 614, the facility's HR and Health Servicesteam will do one final review to ensure that all facility relatedcredentialing and health compliance rules are observed. Any anomaliesare brought to the attention of Compliance Manager by reverting theprofile back to Compliance Manager Queue 612. When the profile meets allthe facility requirements then it is sent to the Orientation Queue 616.

In the Orientation Queue 616, the education services and/or the MSPStaffing Admin will create an orientation schedule from a pre-existingorientation template and send it to the suppler and the candidate. Atthis time, the profile is moved to Orientation Verification Queue 618.While in the orientation queue 616, the results of the orientation areposted in the MSP platform 100 for each orientation segment of process600 completed, and when all steps are marked as done then the profile ismoved to the final segment.

In the final segment of process 600, the profile is marked as completed.Any notes that need to be captured about the candidate are also posted,and the candidate is then moved to the qualified staff pool 620 for thefacility along with the complete history of onboard and related notesfrom all the assessors.

FIG. 7 shows the job order queue 700 for an MSP 106. The MSP 106 createsa job order by clicking create requisition 702 in the screen shown inFIG. 7. The screen for job order queue 700 illustrates where all newlycreated orders are staged.

FIG. 8 shows a job order queue 800 for a supplier 202. Each broadcastedjob order is visible to one or more suppliers 202 as shown in thefigure. A supplier 202 can respond to the requisition, or job order, byclicking propose button 802, which initiates the searching and matchingalgorithm. The action/status column 804 shows the progress of a profilethrough the onboard process along with an indicator showing alldocuments required for credentialing and compliance that are stillpending for the candidate. When MSP 106 selects candidates from the listproposed by the supplier(s) 202, the supplier 202 is able to see whichhealthcare worker 204 was selected by MSP 106.

FIG. 9 illustrates an example search and match screen 900 that shows alleligible candidates to a supplier 202 according to the disclosedembodiments. The search and match function show all eligible candidates902 for a specific job class. This is illustrated below. Also shown isthe onboard status history to prevent over subscription for thecandidate 902. A previously submitted candidate 902, or one that isalready part of another job order, is prevented from resubmission.Compliance alerts are also shown in the context of healthcare-specificrules. FIG. 10 illustrates an example screen 1000 of a supplier 202submitting one or more candidates 902 according to the disclosedembodiments.

Actions pertaining screening queue 606 are disclosed. FIG. 11illustrates a MSP screen 1100 of the screening queue 606 according tothe disclosed embodiments. Proposed healthcare workers 902 are shown inscreening queue 606. The screening document submitted for candidate 902is reviewed for fulfilling the job, as shown in FIG. 11. A coloredindicator 1102 may be used, wherein the colors yellow, green, and redare used to highlight the status of the different candidates 902 shownin screen 1100. Further, screen 1100 may show the status of eachcandidate using process bars 1104, which resemble process 600. Varioustypes of information may be shown in screen 1104.

FIG. 12 illustrates a screen 1200 showing the MSP's Position-Controlforwarding a candidate 902 to an interview queue according to thedisclosed embodiments. When the screening process is complete, acandidate 902 can be rejected or forwarded to interviewer queue 608. Adrop-down menu 1202 may be used to select how the candidate is to betreated.

FIG. 13 illustrates a screen 1300 of the view for MSP 106 of theinterviewer queue 608 according to the disclosed embodiments. FIG. 14illustrates the screen 1400 of the queue 608 for an intervieweraccording to the disclosed embodiments. An interviewer/departmentmanager logs into his/her portal and is presented with screen 1400 ofinterview queue 608. FIG. 15 illustrates the interviewer date selectionscreen 1500 according to the disclosed embodiments. The interviewerselects a candidate 902 for scheduling an interview as shown in thefigure. When an interview date is selected, the system 100 automaticallysends an email or text notification to both the healthcare worker 204and supplier 202. This may be shown in FIG. 16 by interview date displayscreen 1600.

Upon a successful interview, the healthcare worker profile is approved,which automatically forwards the profile to the offer segment of process600. FIG. 17 illustrates the screen 1700 for the MSP view of the offerqueue 610 according to the disclosed embodiments. FIG. 18 illustrates ascreen 1800 showing offer negotiation and confirmation according to thedisclosed embodiments. In the offer segment, the engagement period andall the various terms of engagement are shown. This requires signing byboth the MSP 106, or healthcare facility 102, and the supplier 202.There may be a back-and-forth negotiation, which are depicted in thechat bubble, and recorded for future audit.

Once the offer segment is completed, the profile is transferred to thecompliance manager queue 612 for credentialing and health compliance.This may be an optional compliance step, which is only shown if theoption is turned on. This feature dynamically inserts HR Audit andHealth Audit (Health) steps. These are the credentialing and healthcompliance steps performed by an intervening compliance manager andavailable on demand.

FIG. 19 illustrates the screen 1900 of the MSP view of a compliancemanager queue 612 according to the disclosed embodiments. FIG. 20illustrates a screen 2000 showing the compliance manager queue 612according to the disclosed embodiments. A compliance manager logs intoits portal and sees the compliance manager queue 612 as shown.Compliance manager queue 612 shows all the healthcare workers 204 thatrequire compliance verification. This view also shows if anything isamiss in the documents requested from the suppliers 202. The compliancemanager selects the candidate from the queue to view and approve alldocuments submitted for the onboard to move further along process 600.

FIG. 21 illustrates a screen 2100 for individual health document reviewand approval according to the disclosed embodiments. FIG. 22 illustratesa screen 2200 for individual HR document review and approval accordingto the disclosed embodiments. Screens 2100 and 2200 are broken into twoparts. The top parts 2102 and 2202 are dynamically constructed from thehealthcare facility configuration using the profile elements for thedocumented proof that is mandated. The bottom parts 2104 and 2204 aredynamically constructed from the healthcare facility configuration usingthe checklist created to ensure that the mandated steps are all verifiedbefore allowing a profile to be presented to the healthcare facility'sinternal HR and employee health administrators for another level ofapproval.

Similar to the compliance manager login portal, MSP platform 100 alsoincludes portals for a facility's HR and health services team forvalidating adherence to the facility's internal rules. The approvalprocess used by the HR and health service personnel is identical to thecompliance manager functions. Thus, these steps are skipped here forbrevity.

After all documents are reviewed and approved, the next segment ofprocess 600 is to schedule the healthcare worker 204 to attendorientation. FIG. 23 shows the screen 2300 of the progression as viewedby the administrator of the MSP 106.

FIG. 24 illustrates a screen 2400 showing the MSP admin creating anorientation schedule 2402 according to the disclosed embodiments. FIG.25 illustrates the screen 2500 showing verification of orientation steps2502 according to the disclosed embodiments. FIG. 26 illustrates thescreen 2600 for the MSP view of completion of orientation according tothe disclosed embodiments. FIG. 27 illustrates a screen 2700 showingfinal step to mark onboard completed according to the disclosedembodiments.

Once in orientation queue 618, the MSP Staffing Manager, or anotherstakeholder, will create an orientation schedule 2402 as shown. Theschedule is automatically created from the template earlier created forthe healthcare facility 102 as part of the facility configuration. Theschedule and all its elements are editable. When the dates are updated,the schedule is sent over to supplier 202 and healthcare worker 204.Referring to FIG. 25, each orientation step 2502 is verified as completeonce it is completed.

Upon successful completion of orientation, the healthcare worker profileis staged for the final approval segment. When the onboard is markedcompleted, the healthcare worker 204 is added to the qualified staffpool as shown in FIG. 27. The staff can be monitored for assignments andcontinued compliance. At this time, the healthcare worker 204 can beassigned shifts.

Thus, the disclosed embodiments provide an automated process to begin,plan, and track the identification and certification of a healthcareworker. Each segment of process 600 is tracked so that the position ofthe healthcare worker profile within the MSP platform 100 is known.Further, information is provided in a uniform format across allentities.

MSP platform 100 also may be used as a collaborative scheduling platformthat allows multiday scheduling. This method of scheduling day-to-dayshifts provides a 5-dimensional matrix making it very easy to scheduleshifts for an entire facility on simply one single screen. As shown inFIG. 28, one starts by selecting all departments, shift types, jobclass, and a set of suppliers from the supplier ecosystem. Suppliers canbe selected incrementally i.e. more suppliers can be added later to themultiday day-to-day job order. The resulting 5-dimensional vieworganizes the result set by departments, job classes, availablehealthcare workers, shift-types, and dates. Therefore, hundreds ofshifts can be filled on a single screen in minutes. In the background, aseparate job-order for multiday day-to-day shifts is created for eachhealthcare worker. Optionally, instead of choosing any specifichealthcare worker, a generic broadcast can be sent for desired number ofhealthcare workers required for a given day for the combination ofdepartment, job class, shift-type, and dates.

This same mechanism can be used for travel staff (as against day-to-daystaff) as well. The only difference is that the travel staff isinstantly confirmed as they are pre-booked for a specific contractperiod, whereas the day-to-day staff is requested for reciprocating witha confirmation by either the healthcare worker or its supplierrepresentative.

FIG. 28 illustrates a selection criteria screen 2800 for creation of a5-dimensional view according to the disclosed embodiments. Criteria areshown for selection in fields. One selects data from the fields to buildthe view. Screen 2800 includes department field 2802, shift type field2804, class field 2806, and agency field 2808. Other information may beshown on screen 2800 pertaining the healthcare facility 102 and thelike.

FIG. 29 illustrates a screen 2900 of the 5-dimensional view on executingsearches according to the disclosed embodiments. Each cell 2901 in thescreen 2900 is clickable to do additional actions such as cancel a shiftor cancel a specific healthcare worker (but keep the shift). Color codes2902 explain the status of each cell. For example, orange implies that aspecific healthcare worker has been invited and waiting acceptance bythe worker or its supplier. Green indicates that the position wassuccessfully filled. Red indicates that the shift was declined for thenamed healthcare worker. Pink indicates that the healthcare workercalendar shows that the slot coinciding with the shift-type is marked asavailable for taking new shifts. Another availability status is denotedby a question mark in the cell, which means that the slot is neitherblocked nor available. In other words, the disposition of the slot isambiguous and may possibly require a call to the healthcare worker toconfirm availability.

The MSP platform 100 also enables single day scheduling, or the dailyview. This method of scheduling day-to-day shifts provides a3-dimensional matrix making it very easy to schedule shifts for anentire facility by dynamically creating a single screen. As shown inFIG. 30, one starts by selecting all departments, shift types, jobclass, and a set of suppliers from the supplier ecosystem. Suppliers 202can be selected incrementally, i.e. more suppliers can be added later tothe day-to-day job order.

FIG. 30 illustrates a screen 3000 of selection criteria for creation ofa 3-dimensional view according to the disclosed embodiments. Criteriaare shown for selection in fields. One selects data from the fields tobuild the view. Screen 3000 includes department field 3002, shift typefield 3004, class field 3006, and agency field 3008. Other informationmay be shown on screen 3000 that pertains to the healthcare facility 102and the like.

FIG. 31 illustrates a screen 3100 for the 3-dimensional view onexecuting searches according to the disclosed embodiments. The resulting3-dimensional view shown is organized by departments 3102, dates (asswim lanes) 3104, and available healthcare workers (identifying both theshift-types and job-class) 3106. This feature provides the ability toview daily outstanding needs and contingent healthcare workers workingon that day created by any of 3 methods discussed in this document.Requesting specific healthcare workers for a specific day will create anew day-to-day job order for only that day and shift-type. Optionally,instead of choosing any specific healthcare worker, a generic broadcastcan be sent for desired number of healthcare workers required for agiven day for the combination of department, job class, and shift-type.Colors 3108 also are used to indicate status of the shifts and theworkers shown therein.

This same mechanism can be used for travel staff (as against day-to-daystaff) as well. The only difference is that the travel staff isinstantly confirmed as they are pre-booked for a specific contractperiod, whereas the day-to-day staff is requested for reciprocalconfirmation by either the healthcare worker or its supplierrepresentative.

FIG. 32 illustrates a screen 3200 for a consolidated view for a supplier202 from all healthcare facilities 102 according to the disclosedembodiments. Supplier view is basically a catchall bucket. Day-to-dayshift requests for all health facilities, for all shift types andjob-classes, are presented in the day column. This simplified viewallows a supplier to see the demand-by-date in one consolidated queuefrom all healthcare facilities. Therefore, the supplier 202 can also seeconflicting requests for same person, or more demand for a given day,and can adjust the resources accordingly, while also offeringreplacement candidates in cases where named-workers in job orders cannotbe made available because of multiple opportunities.

The MSP platform 100 also enables VoIP-enabled multiday scheduling. Inthis method of scheduling, a multidimensional search on healthcareworkers is performed based on department, job class, shift-type, and oneor more dates as shown. This feature is different from the multidayscheduling discussed earlier where a calendar based availability screenis created for the entire staff pool qualified for the shift. In thecurrent VoIP-based scenario, the available staff is shown based on datesand other parameters provided, which keeps the view limited in scope,and contextualized to specific parameters.

FIG. 33 illustrates a search screen 3300 for VoIP multiday schedulingaccording to the disclosed embodiments. There are differences from theprevious screens for multiday and daily scheduling disclosed above.Screen 3300 includes months field 3302 showing the months available forscheduling. Within the months, dates 3304 also are shown for selection.Selected dates 3305 also may be shown as blacked out or colored in somemanner. The search may be done for a specific healthcare facility 102,as specified in facility field 3308.

FIG. 34 illustrates a MSP pre-VoIP view screen 3400 for VoIP-enabledinvitations for day-to-day job orders according to the disclosedembodiments. The healthcare workers 204 satisfying the search criteriaspecified in screen 3300 are listed in view screen 3400 along with theiravailability marked for each day included in the day-to-day multiday joborder. The job order may be reflected by field 3402, which lists theparameters for the job order. Candidates 3404 are shown along with abutton 3406 to broadcast the job order across multiple agencies.

When the entire shift period matches the healthcare worker availabilityin the worker's virtual calendar, the related slot is represented by agreen checkmark 3408. A worker has a single virtual calendar sharedacross all employers, and this prevents scheduling conflicts. If theentire shift period is undeclared or unspecified for availability, thensuch slots are depicted by a question mark 3410 implying that thecandidate may be available and needs to be contacted for confirmationbefore allocating the candidate to the shift. If a worker is alreadyunavailable because of leave or blocked by another fully or partiallyoverlapping shift then the corresponding cell is shown as blank 3412meaning unavailable. When multiple candidates are available to fill amultiday shift, then the days can be distributed among severalhealthcare workers. This is done on the facility side by removingspecific days by clicking on the check mark or the question mark in eachcell, which excludes the day from being allocated to the healthcareworker. In this fashion, opportunities can be fairly distributed.

A phone icon 3414 is provided against an available healthcare worker ifall corresponding slots are checked. If there are any question marks,then those days need to be first removed. The MSP platform 100 candirectly contact either the candidate or its representative supplier viaVoIP. The VoIP logic automatically announces all the parameters of theshift along with the name of the candidate selected, and the recipientof the call can respond by either declining or accepting the shift byappropriately punching the right options announced on their phonekeypad. When multiple suppliers 202 are processing the same order overVoIP, and if the job-order is designated as BID then multiple candidatescan be queued in the facility's day-to-day queue; from these submissionsonly the order-provided number of workers can be CONFIRMED or GUARANTEEDwhile sending an automated declination to others. If the order type iseither CONFIRMED or GUARANTEED, then acceptance of any day within amultiday day-to-day job order is awarded on first come first serve basisand all new acceptances blocked as soon as the shift limit for aspecific day is met.

FIG. 35 illustrates the MSP view screen 3500 showing the healthcareworker 3502 in the invited queue according to the disclosed embodiments.FIG. 36 illustrates the supplier view screen 3600 when the healthcareworker 3502 is moved to the BID queue on accepting the shift(s)according to the disclosed embodiments. FIG. 37 illustrates the supplierview screen 3700 when the healthcare worker 3502 is moved to theconfirmed queue on accepting the shift(s) according to the disclosedembodiments. These screens are disclosed in greater detail below.

These figures highlight the provision for sending manual invites. Manualinvites are helpful to suppliers 202 by providing facility-like featuresin declining certain days for certain employees. This feature helps indistributing shifts across multiple healthcare workers 204 while alsoproviding the ability to decline candidates that were available at thetime of multiday day-to-day job-order creation, but are no longeravailable at the time of accepting the shift.

When multiple suppliers are processing the same order, and if thejob-order is designated as BID, then multiple candidates can be queuedin the facility's day-to-day queue. From these submissions, only theorder-provided number of workers can be selected while sending anautomated declination to others. FIG. 36 shows the supplier view whenaccepting a BID shift in a multiday day-to-day job order.

If the order type is either CONFIRMED or GUARANTEED, then acceptance ofany day within a multiday day-to-day job order is awarded on first comefirst serve basis and all new acceptances are blocked as soon as theshift limit for a specific day is met. FIG. 37 shows the supplier viewwhen accepting a CONFIRMED shift in a multiday day-to-day job order.When shifts are accepted using either VoIP or manually, a backingtimecard is immediately created for CONFIRMED or GUARANTEED shift type.This timecard is shown when the healthcare worker 3502 arrives onsite atthe facility. The timecard is available to the healthcare workers ontheir mobile device.

It is not always necessary to send manual invites or use VoIP. Amultiday day-to-day job order without candidates can be send using theBROADCAST mechanism. In this case, the suppliers can fill the candidatesof their choice from all available healthcare workers. Regardless ofwhether broadcast was used or workers invited by name, the AVAILABLEslot shown in the figures above always scans the system to check for newavailability. Therefore, these types of orders are considered to bereal-time orders as the order is constantly aware about the changingavailability across the ecosystem regardless of which supplier is seeingthe job order. Each candidate in the AVAILABLE pool is tagged with aPROPOSE button. A PROPOSE is identified on the MSP side with a differentcolor, such as a yellow background, to indicate the proposed candidate3502 was in response to a broadcasted job-order, or was offered in placeof another worker originally named in the job order. However, theAVAILABLE tab only shows the workers who have completed onboard with aspecific hospital associated with the order and the onboard was done inthe context of the supplier. This creates a dedicated relationshipbetween the supplier and the healthcare facility in the context of thenamed candidate such that no other supplier can propose the samecandidate.

Thus, the disclosed embodiments allow for scheduling across multiplefacilities, suppliers and pools of healthcare workers. Information onshifts and filled slots is updated instantaneously. A healthcarefacility may use the disclosed view screen to select and notifycandidates of available shifts. Several suppliers may access the samescreens such that the scheduling information is consistent throughoutthe system. Conflicts are avoided using the disclosed platform.

FIG. 38 depicts a managed service provider system 3800 for managingcollaborative credentialing, compliance, and scheduling of contingenthealthcare workers by multiple MSPs and healthcare facilities accordingto the disclosed embodiments. Other components may be included in system3800 not shown in FIG. 38. The disclosure of FIG. 38 is shown forclarity and may include any of these additional components to performthe functionality disclosed herein.

System 3800 may include local area networks (LAN) and wide area network(WAN) shown as network 3806 and wireless network 3810. Gateway 3808 isconfigured to connect remote or different types of networks together, aswell as client computing devices 3812-3818 and server computing devices3802-3804.

Client computing devices 3812-3818 may include any device capable ofreceiving and sending data over a network, such as wireless network3810. Devices 3812-3818 may include portable devices such as cellulartelephones, smart phones, radio frequency-enabled devices, personaldigital assistants, handheld computers, tablets, laptop computers,wearable computers and the like. Devices 3812-3818 also may include anycomputing device that connects to a network using a wired communicationsmedium such as personal computers, multiprocessor systems,microprocessor-based or programmable consumer electronics, networkpersonal computers and the like.

Client computing devices 3812-3818 also may be web-enabled clientdevices that include a browser application configured to receive and tosend web pages, web-based messages and the like. The browser applicationmay be configured to receive and display graphic, text, multimedia, orthe like, employing virtually any web based language, including awireless application protocol messages (WAP), or the like. In oneembodiment, the browser application may be enabled to employ one or moreof Handheld Device Markup Language (HDML), Wireless Markup Language(WML), WMLScript, JavaScript, Standard Generalized Markup Language(SMGL), HyperText Markup Language (HTML), eXtensible Markup Language(XML), or the like, to display and send information.

Client computing devices 3812-3818 also may include at least one otherclient application that is configured to receive content from anothercomputing device, including, without limit, server computing devices3802-3804. The client application may include a capability to provideand receive textual content, multimedia information, or the like. Theclient application may further provide information that identifiesitself, including a type, capability, name, or the like. In oneembodiment, client devices 3812-3818 may uniquely identify themselvesthrough any of a variety of mechanisms, including a phone number, mobileidentification number (MIN), an electronic serial number (ESN), mobiledevice identifier, network address, such as IP (Internet Protocol)address, media access control (MAC) layer identifier, or otheridentifier. The identifier may be provided in a message, or the like,sent to another computing device.

Client computing devices 3812-3818 may also be configured to communicatea message, such as through email, short message service (SMS),multimedia message service (MMS), instant messaging (IM), internet relaychat (IRC), Mardam-Bey's IRC (mIRC), Jabber, or the like, to anothercomputing device.

Client devices 3812-3818 may further be configured to include a clientapplication that enables the user to log into a user account that may bemanaged by another computing device. Such a user account, for example,may be configured to enable the user to receive emails, send/receive IMmessages, SMS messages, access selected web pages, download scripts,applications, or a variety of other content, or perform a variety ofother actions over a network. Management of messages or otherwiseaccessing and/or downloading content, may also be performed withoutlogging into the user account. Thus, a user of client devices 3812-3818may employ any of a variety of client applications to access content,read web pages, receive/send messages, or the like.

In one embodiment, for example, the user may employ a browser or otherclient application to access a web page hosted by a Web serverimplemented as server computing device 3802. Messages received by clientcomputing devices 3812-3818 may be saved in non-volatile memory, such asflash and/or PCM, across communication sessions and/or between powercycles of client computing devices 3812-3818.

Wireless network 3810 may be configured to couple client devices3814-3818 to network 3806. Wireless network 3810 may include any of avariety of wireless sub-networks that may further overlay stand-alonead-hoc networks, and the like, to provide an infrastructure-orientedconnection for client devices 3814-3818. Such sub-networks may includemesh networks, Wireless LAN (WLAN) networks, cellular networks, and thelike. Wireless network 3810 may further include an autonomous system ofterminals, gateways, routers, and the like connected by wireless radiolinks, and the like. These connectors may be configured to move freelyand randomly and organize themselves arbitrarily, such that the topologyof wireless network 3810 may change rapidly.

Wireless network 3810 may further employ a plurality of accesstechnologies including 2nd (2G), 3rd (3G), 4th (4G), 5th (5G) and thelike generation radio access for cellular systems, WLAN, Wireless Router(WR) mesh, and the like. Access technologies such as 2G, 3G, 4G, 5G andfuture access networks may enable wide area coverage for mobile devices,such as client devices 3814-3818 with various degrees of mobility. Forexample, wireless network 3810 may enable a radio connection through aradio network access such as global system for mobile communication(GSM), general packet radio services (GPRS), enhanced data GSMenvironment (EDGE), WEDGE, Bluetooth, high speed downlink packet access(HSDPA), universal mobile telecommunications system (UMTS), Wi-Fi,Zigbee, wideband code division multiple access (WCDMA), and the like. Inessence, wireless network 3810 may include virtually any wirelesscommunication mechanism by which information may travel between clientdevices 3802-3804 and another computing device, network, and the like.

Network 3806 is configured to couple one or more servers depicted inFIG. 38 as server computing devices 3802-3804 and their respectivecomponents with other computing devices, such as client device 3812, andthrough wireless network 3810 to client devices 3814-3818. Network 3806is enabled to employ any form of computer readable media forcommunicating information from one electronic device to another. Network3806 also may include the Internet in addition to local area networks(LANs), wide area networks (WANs), direct connections, such as through auniversal serial bus (USB) port, other forms of computer-readable media,or any combination thereof. On an interconnected set of LANs, includingthose based on differing architectures and protocols, a router acts as alink between LANs, enabling messages to be sent from one to another.Network 3806 may include any communication method by which informationmay travel between computing devices. Additionally, communication mediatypically may enable transmission of computer-readable instructions,data structures, program modules, or other types of content, virtuallywithout limit. By way of example, communication media includes wiredmedia such as twisted pair, coaxial cable, fiber optics, wave guides,and other wired media and wireless media such as acoustic, RF, infrared,and other wireless media.

FIG. 39 depicts a computing device 3900 configured to execute thefunctionality disclosed in greater detail below. Computing device 3900may communicate with other devices over system 3800 to perform thefunctions needed for managing collaborative credentialing, compliance,and scheduling of contingent healthcare workers by multiple MSPs andhealthcare facilities. Computing device 3900 may be representative ofany of the computing devices shown in FIG. 38.

Computing device 3900 includes optical storage 3902, central processingunit (CPU) 3904, memory module 3906, display interface 3914, audiointerface 3916, input devices 3918, input/output (I/0) processor 3920,bus 3922, non-volatile memory 3924, various other interfaces 3926-3928,network interface card (NIC) 3930, hard disk 3932, power supply 3934,transceiver 3936, antenna 3938, haptic interface 3940, and globalpositioning system (GPS) unit 3942. Memory module 3906 may includesoftware such as operating system (OS) 3908, and a variety of softwareapplication programs and/or software modules/components 3910-3912. Suchsoftware modules and components may be stand-alone application softwareor be components, such as DLL (Dynamic Link Library) of largerapplication software.

Computing device 3900 may also include other components not shown inFIG. 39. For example, computing device 3900 may further include anilluminator (for example, a light), graphic interface, and portablestorage media such as USB drives. Computing device 3900 may also includeother processing units, such as a math co-processor, graphicsprocessor/accelerator, and a Digital Signal Processor (DSP).

Optical storage device 3902 may include optical drives for using opticalmedia, such as CD (Compact Disc), DVD (Digital Video Disc), and thelike. Optical storage devices 3902 may provide inexpensive ways forstoring information for archival and/or distribution purposes.

Central processing unit (CPU) 3904 may be the main processor forsoftware program execution in computing device 3900. CPU 3904 mayrepresent one or more processing units that obtain software instructionsfrom memory module 3906 and execute such instructions to carry outcomputations and/or transfer data between various sources anddestinations of data, such as hard disk 3932, I/0 processor 3920,display interface 3914, input devices 3918, non-volatile memory 3924,and the like.

Memory module 3906 may include RAM (Random Access Memory), ROM (ReadOnly Memory), and other storage means, mapped to one addressable memoryspace. Memory module 3906 illustrates one of many types of computerstorage media for storage of information such as computer readableinstructions, data structures, program modules or other data. Memorymodule 3906 may store a basic input/output system (BIOS) for controllinglow-level operation of computing device 3900. Memory module 3906 mayalso store OS 3908 for controlling the general operation of computingdevice 3900. It will be appreciated that OS 3908 may include ageneral-purpose operating system such as a version of UNIX, or aspecialized client-side and/or mobile communication operating system. OS3908 may, in turn, include or interface with a Java virtual machine(JVM) module that enables control of hardware components and/oroperating system operations via Java application programs.

Memory module 3906 may further include one or more distinct areas (byaddress space and/or other means), which can be utilized by computingdevice 3900 to store, among other things, applications and/or otherdata. For example, one area of memory module 3906 may be set aside andemployed to store information that describes various capabilities ofcomputing device 3900, a device identifier, and the like. Suchidentification information may then be provided to another device basedon any of a variety of events, including being sent as part of a headerduring a communication, sent upon request, or the like.

One common software application is a browser program that is generallyused to send/receive information to/from a web server. In oneembodiment, the browser application is enabled to employ handheld devicemarkup language (HDML), wireless markup language (WML), WMLScript,JavaScript, standard generalized markup language (SMGL), hypertextmarkup language (HTML), eXtensible markup language (XML), and the like,to display and send a message. Any of a variety of other web basedlanguages may also be employed. In one embodiment, using the browserapplication, a user may view an article or other content on a web pagewith one or more highlighted portions as target objects.

Display interface 3914 may be coupled with a display unit 3990, such asliquid crystal display (LCD), gas plasma, light emitting diode (LED), orany other type of display unit that may be used with computing device3900. Display unit 3990 coupled with display interface 3914 may alsoinclude a touch sensitive screen arranged to receive input from anobject such as a stylus or a digit from a human hand. Display interface3914 may further include interface for other visual status indicators,such light emitting diodes (LED), light arrays, and the like. Displayinterface 3914 may include both hardware and software components. Forexample, display interface 3914 may include a graphic accelerator forrendering graphic-intensive outputs on the display unit. In oneembodiment, display interface 3914 may include software and/or firmwarecomponents that work in conjunction with CPU 3904 to render graphicoutput on the display unit.

Audio interface 3916 is arranged to produce and receive audio signalssuch as the sound of a human voice. For example, audio interface 3916may be coupled to a speaker and microphone to enable communication witha human operator, such as spoken commands, and/or generate an audioacknowledgement for some action.

Input devices 3918 may include a variety of device types arranged toreceive input from a user, such as a keyboard, a keypad, a mouse, atouchpad, a touch-screen (described with respect to display interface3914), a multi-touch screen, a microphone for spoken command input(describe with respect to audio interface 3916), and the like.

I/O processor 3920 is generally employed to handle transactions andcommunications with peripheral devices such as mass storage, network,input devices, display, and the like, which couple computing device 3900with the external world. In small, low power computing devices, such assome mobile devices, functions of the I/O processor 3920 may beintegrated with CPU 3904 to reduce hardware cost and complexity. In oneembodiment, I/O processor 3920 may the primary software interface withall other device and/or hardware interfaces, such as optical storage3902, hard disk 3932, interfaces 3926-3928, display interface 3914,audio interface 3916, and input devices 3918.

An electrical bus 3922 internal to computing device 3900 may be used tocouple various other hardware components, such as CPU 3904, memorymodule 3906, I/0 processor 3920, and the like, to each other fortransferring data, instructions, status, and other similar information.

Non-volatile memory 3924 may include memory built into computing device3900, or portable storage medium, such as USB drives that may includePCM arrays, flash memory including NOR and NAND flash, pluggable harddrive, and the like. In one embodiment, portable storage medium maybehave similarly to a disk drive. In another embodiment, portablestorage medium may present an interface different than a disk drive, forexample, a read-only interface used for loading/supplying data and/orsoftware.

Various other interfaces 3926-3928 may include other electrical and/oroptical interfaces for connecting to various hardware peripheral devicesand networks, such as IEEE 1394 also known as FireWire, Universal SerialBus (USB), Small Computer Serial Interface (SCSI), parallel printerinterface, Universal Synchronous Asynchronous Receiver Transmitter(USART), Video Graphics Array (VGA), Super VGA (SVGA), and the like.

Network interface card (NIC) 3930 may include circuitry for couplingcomputing device 3900 to one or more networks, and is generallyconstructed for use with one or more communication protocols andtechnologies including, but not limited to, global system for mobilecommunication (GSM), code division multiple access (CDMA), time divisionmultiple access (TDMA), user datagram protocol (UDP), transmissioncontrol protocol/Internet protocol (TCP/IP), SMS, general packet radioservice (GPRS), WAP, ultra-wide band (UWB), IEEE 802.16 WorldwideInteroperability for Microwave Access (WiMax), SIP/RTP, Bluetooth,Wi-Fi, Zigbee, UMTS, HSDPA, WCDMA, WEDGE, or any of a variety of otherwired and/or wireless communication protocols.

Hard disk 3932 is generally used as a mass storage device for computingdevice 3900. In one embodiment, hard disk 3932 may be a Ferro-magneticstack of one or more disks forming a disk drive embedded in or coupledto computing device 3900. Alternatively, hard drive 3932 may beimplemented as a solid-state device configured to behave as a diskdrive, such as a flash-based hard drive. In yet another embodiment, harddrive 3932 may be a remote storage accessible over network interface3930 or another interface 3926, but acting as a local hard drive.

Power supply 3934 provides power to computing device 3900. Arechargeable or non-rechargeable battery may be used to provide power.The power may also be provided by an external power source, such as anAC adapter or a powered docking cradle that supplements and/or rechargesa battery.

Transceiver 3936 generally represents transmitter/receiver circuits forwired and/or wireless transmission and receipt of electronic data.Transceiver 3936 may be a stand-alone module or be integrated with othermodules, such as NIC 3930. Transceiver 3936 may be coupled with one ormore antennas for wireless transmission of information.

Antenna 3938 is generally used for wireless transmission of information,for example, in conjunction with transceiver 3936, NIC 3930, and/or GPS3942. Antenna 3938 may represent one or more different antennas that maybe coupled with different devices and tuned to different carrierfrequencies configured to communicate using corresponding protocolsand/or networks. Antenna 3938 may be of various types, such asomni-directional, dipole, slot, helical, and the like.

Haptic interface 3940 is configured to provide tactile feedback to auser of computing device 3900. For example, the haptic interface may beemployed to vibrate computing device 3900, or an input device coupled tocomputing device 3900. For example, when a message is received by device3900 or another event occurs, the device may vibrate to alert the user.

Global positioning system (GPS) unit 3942 can determine the physicalcoordinates of computing device 3900 on the surface of the Earth, whichtypically outputs a location as latitude and longitude values. GPS unit3942 can also employ other geo-positioning mechanisms, including, butnot limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA,BSS or the like, to further determine the physical location of computingdevice 3900 on the surface of the Earth. It is understood that underdifferent conditions, GPS unit 3942 can determine a physical locationwithin millimeters for computing device 3900. In other cases, thedetermined physical location may be less precise, such as within a meteror significantly greater distances. In one embodiment, however, a mobiledevice represented by computing device 3900 may, through othercomponents, provide other information that may be employed to determinea physical location of the device, including for example, a MAC address.

Using instructions stored in memory module 3906, device 3900 may readthe instructions to have CPU 3904 execute the functions specified in theinstructions. These functions are disclosed in greater detail by FIGS.3A, 3B and 4. Thus, computing device 3900 is configured to be a specialpurpose device for managing collaborative credentialing, compliance, andscheduling of contingent healthcare workers by multiple MSPs andhealthcare facilities.

It will be apparent to those skilled in the art that variousmodifications and variations can be made in the disclosed embodiments ofthe disclosed device and associated methods without departing from thespirit or scope of the invention. Thus, it is intended that the presentinvention covers the modifications and variations of the embodimentsdisclosed above provided that the modifications and variations comewithin the scope of any claims and their equivalents.

1. A computerized method for scheduling healthcare workers using amanaged service provider (MSP) platform, the method comprising:providing a central processing unit for retrieving, obtaining, storing,and analyzing healthcare worker profiles and healthcare facilityschedules, wherein the central processing unit executes instructionsstored in a database and causes the storage and retrieval of healthcareworker profiles and healthcare facility schedules in a memory, whereinthe central processing unit executes instructions stored in a databaseand causes analysis of healthcare worker profiles and healthcarefacility schedules; communicatively connecting the central processingunit to at least two entities, wherein the first entity is a healthcareworker's electronic device and the second entity is the healthcarefacility's electronic device, wherein the communicative connection isobtained through a wireless network that is used for bi-directionalcommunication between the healthcare worker and healthcare facility;identifying shifts at a healthcare facility; indicating criteria for theshifts, wherein a shift is a fixed block of time for a specific day ofthe week; causing the central processing unit to electronically analyzeand evaluate profiles of healthcare workers to match the criteria;showing the matched healthcare workers on a display screen; andcontacting the matched healthcare workers using the wireless network. 2.The method of claim 9, further comprising the central processing unitcausing the display of a Virtual Calendar on one or more electronicdevices, wherein the virtual calendar tracks availability of ahealthcare worker and shift allocations across multiple staffingagencies and healthcare facilities, wherein the virtual calendar isdirectly tied to at least one job order, including information relatedto a job order, wherein the Virtual Calendar further provides real-timestatus of a healthcare worker availability allowing the MSP platform tohave real-time capabilities in selecting, inviting and confirmingcandidates using automated job publication or VoIP, the real-timecapabilities further allow the MSP platform to determine whetherappropriate resources are available across a supplier ecosystem tohandle contingencies when there is a no show of a regular healthcareemployee or if the census change requires more healthcare workers to beassigned.
 3. The method of claim 10, wherein the Virtual Calendar isused by a healthcare facility to manage each regular as well ascontracted employee.
 4. The method of claim 10, wherein the VirtualCalendar is accessible by all staffing agencies and healthcarefacilities where the healthcare worker is employed, however the calendarviewed by an agency displays only those shifts that are contractedthrough the agency, and the calendar viewed by a healthcare facilitydisplays only those shifts that are pertaining to the healthcarefacility, thereby obfuscating all virtual calendar entries from theagency and healthcare facility that do not pertain to them.
 5. Themethod of claim 9, further comprising a Staffing Manager, wherein theStaffing Manager uses a 5 dimensional drilldown approach to includedepartments, job class, shift types, date, and time intersection, anddisplays the 5 dimensional data for multi-department, multi-class,multi-shift type, multi-date, and multi-worker selection to provide aview derived from existing shift allocations attached to job orders forthe healthcare facility and virtual calendars of healthcare workersacross the entire supplier ecosystem, wherein each shift has a backingtimecard accessible by healthcare worker using mobile device.
 6. Themethod of claim 9, further comprising a Staffing Manager, wherein theStaffing Manager searches, invites, and confirms based on constructingdate specific horizontal swim-lanes by available staff to provide a viewused for distributing a multiday order between candidates bymix-and-match, with automated VoIP based interaction to confirm multidayavailability, wherein the view is derived from the virtual calendars ofhealthcare workers across the entire supplier ecosystem, and whereineach shift has a backing timecard accessible by healthcare worker usingmobile device.
 7. The method of claim 9, further comprising a StaffingManager, wherein the Staffing Manager searches, invites, and confirmsbased on constructing date specific vertical swim-lanes grouped bydepartment to provide a view derived from the virtual calendars ofhealthcare workers across the entire supplier ecosystem, wherein eachshift has a backing timecard accessible by healthcare worker usingmobile device.
 8. The method of claim 9, further comprising a StaffingManager, wherein the Staffing Manager creates an orientation schedulefor the matched healthcare worker.
 9. The method of claim 16, whereinthe central processing unit presents a drop down menu on the displayscreen for each interviewer listed on the orientation schedule, whereinthe drop down menu provides the option to either recommend or deny thehealthcare worker.
 10. The method of claim 16, wherein the StaffingManager stages the healthcare worker's profile for final approvalsegment once the healthcare worker successfully completes theorientation.
 11. The method of claim 18, wherein the orientation isdesignated as successful if at least ⅔^(rd) majority of the interviewersthat have interviewed the healthcare worker have recommended thehealthcare worker for next stage of the hiring process.
 12. The methodof claim 19, wherein the next stage of hiring process is the onboardingof the healthcare worker.
 13. The method of claim 20, wherein onboardingincludes verification of healthcare workers' background, healthcareworkers' credentialing, and compliance with required policies andprocedures of the healthcare facility.
 14. The method of claim 20,wherein the healthcare worker is added to the qualified staff pool onceonboarding is marked completed.
 15. The method of claim 15, wherein aswim lane is a 3-dimensional view that is organized by variousdepartments at a healthcare facility.
 16. The method of claim 9, whereinthe electronic analysis and evaluation of profiles of healthcare workersfurther comprises using a compliance manager to dynamically determine ifthe healthcare worker is compliant to the required policies andprocedures of the healthcare facility.
 17. The method of claim 24,wherein the compliance manager approves the healthcare worker to work ashift at the healthcare facility only if the healthcare worker iscompliant with the required policies and procedures of the healthcarefacility.
 18. The method of claim 24, wherein the compliance furtherperforms the steps of: dynamically generating a complete list of allrequired credentials, wherein the list of requirements is specificallyconfigured for each healthcare facility, that are needed for approval ofa healthcare worker, comparing the complete required list of credentialsand health compliance documents with a subset of credentials and healthcompliance documents already received by the healthcare facility,identifying the missing set of credentials and health compliancedocuments based on the comparison performed, and alerting an agencyresponsible for the healthcare worker to submit only those credentialsand health compliance documents that are deemed missing and would makethe list complete for approval.
 19. The method of claim 19, wherein thecompliance manager approves the healthcare worker if the status of thehealthcare worker's license, certifications, and health compliance iscurrent to date.
 20. The method of claim 19, wherein the compliancemanager approves the healthcare worker if healthcare worker's backgroundverification meets the healthcare facility's criterion.